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1.  INTRODUCTION 

This  Quarterly  Technical  Report  No,  4  describes  several 
aspects  of  cur  progress  on  the  ARPA  computer  network  during  the 
fourth  quarter  of  1969.  During  this  period,  the  installation  of 
a  four-node  initial  network  connecting  UCLA,  UCSB,  SRI ,  and  Utah 
was  completed  on  schedule.  A  second  version  of  the  operational 
IMP  program  which  replaced  the  earlier  version  was  released  on 
November  2.  The  continuing  software  development  activity  is 
described  in  Section  2.  Work  was  also  completed  on  the  imple¬ 
mentation  of  a  hardware  add-on  to  the  standard  Host/IMP  interface 
unit  to  drive  a  2300-foot  Host  cable.  This  work  is  described  in 
Section  3. 

An  initial  version  of  a  phone  line  test  program  was  written 
during  this  quarter  in  order  to  obtain  data  on  the  performance  of 
the  wideband  communication  circuits.  This  program  and  our  ini¬ 
tial  experience  in  using  it  is  described  in  Section  4.  A  slight 
modification  to  the  IMP 1 s  RFNM  mechanism  resulted  from  our  dis¬ 
cussions  with  the  Hosts  in  the  initial  network.  Our  participation 
in  the  effort  to  develop  a  sensible  Host  protocol  is  described  in 
Section  5. 
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2.  SOFTWARE  DEVELOPMENT 

During  this  quarter,  version  two  of  the  operational  program 
was  delivered  to  the  sites.  This  new  version  incorporates  most 
of  the  features  previously  described  in  our  technical  reports, 
su2h  as  s.  complete  set  of  measurement  facilities,  and  includes  a 
new  status  reporting  feature. 

In  order  tc  incorporate  these  measurement  facilities,  we 
made  a  substantial  effort  to  utilize  the  existing  program  routines. 
As  a  result,  it  ti as  decided  that  the  IMP  should  use  the  Host/IMP 
and  IMP/Host  routines  to  handle  messages  generated  by  or  destined 
for  an  IMP  and  thus  to  treat  these  IMP  messages  as  if  they  were 
Host  mess  ages . 

An  IMP  message  is  iistinguished  from  a  Host  message  by  a 
digit  1  in  the  FOR  IMP  or  FROM  IMP  bit  in  the  leader  of  the  mes¬ 
sage.  A  message  from  an  IMP  is  identified  by  a  1  in  the  FROM  IMP 
bit  position  in  the  leader;  likewise,  a  message  to  an  IMP  Is  iden¬ 
tified  by  a  1  in  the  FOR  IMP  bit  position  of  the  leader.  The 
particular  type  of  IMP  message  Is  designated  by  the.  two  Host  bits 
in  the  leader.  The  RFNM  mechanism  works  in  the  usual  fashion  for 
IMP  messages.  A  detailed  description  of  the  formats  for  communi¬ 
cation  between  a  Host  and  an  IMP  will  he  incorporated  into  BBN 
Report  No,  1822,  the  Host  Specification.  A  typical  Host  will 
ordinarily  have  little  need  to  communicate  directly  with  an  IMP. 
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The  various  types  of  messages  to  and  from  an  IMP  are  illus- 
i  trated  in  Figure  1  and  are  described  below: 

1)  TELETYPE  -  FOR  IMP  messages  of  type  0  are  printed  out  on  the 

IMP  teletype.  FROM  IMP  messages  of  type  0  are 
generated  at  the  IMP  teletype. 

|  2)  DEBUG  -  DEBUG  messages  are  used  to  examine,  modify,  and 

report  the  contents  of  registers  in  core.  Mes- 
|  sages  to  and  from  DEBUG  are  designated  by  type  1. 

The  IMP  software  prevents  the  unauthorized  use  of 
I  the  DEBUG  program. 

3)  TRACE  -  When  this  feature  is  activated  (using  PARAMETER 

|  CHANGE),  the  IMP  program  records  and  transmits 

1  information  about  packets  that  have  been  marked 

for  tracing.  This  FROM  IMP  information  is  desig- 

I 

1  nated  by  type  ?. 

4)  STATISTICS  -  When  this  feature  is  activated,  the  IMP  program 

performs  measurements  on  network  activity  and 
transmits  this  information  to  a  designated  desti¬ 
nation*  This  FROM  IMP  information  is  designated 
by  type  3. 

5)  PARAMETER  -  An  authorized  Host  can  send  a  message  to  an  IMP 

CHANGE  that  causes  preselected  IMP  parameters  to  be 

modified.  This  FOR  IMP  message  should  be  of 
type  2. 

6)  DISCARD  -  The  IMP  program  will  discard  any  FOR  IMP  message 

of  type  3. 
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FIG.  1.  COMMUNICATION  WITH  AN  IMP. 


Report  No.  1928 


Bolt  Beranek  and  Newman  Inc. 


The  status  reporting  mechanism  provides  current  information 
about  the  condition  of  the  network.  When  activated  at  a  given 
IMP,  this  mechanism  periodically  forms  a  message  that  records  the 
status  of  the  Host,  the  phone  lines,  and  the  sense  switches,  A 
new  status  message  is  formed  and  transmitted  every  ten  minutes  to 
the  control  center  and  also  whenever  live/dead  status  changes 
occur.  These  messages  are  printed  on  the  IMP  teletype  at  the  con¬ 
trol  center  in  the  following  form: 

IMP  HOST  LINE  1  LINE  2  LINE  3  SENSE 

jH  STATUS  STATUS  STATUS  STATUS  SWITCH 

STATUS 

The  Host  and  line  status  entries  denote  the  respective  live./ 
dead  conditions.  In  addition,  the  line  status  entries  also  denote 
the  number  of  retransmitted  packets  on  that  line  in  the  last  twen¬ 
ty  recorded  tries.  The  sense  switch  status  entry  records  the  posi¬ 
tion  of  each  sense  switch.  The  format  will  be  modified  to  include 
additional  lines  and  hosts  as  needed.  An  up-to-date  record  of  the 
network  status  is  thus  available  at  the  control  center  whenever 
this  feature  is  activated. 
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3.  HARDWARE  DEVELOPMENT 

During  the  last  quarter,  we  developed  a  prototype  distant 
Host  driver  that  may  be  added  to  the  standard  interface  to  permit 
connection  of  a  Host  to  an  IMP  at  distances  up  to  2000  ft.  The 
inclusion  of  a  distant  Host  driver  does  not  change  the  logical 
operation  of  the  Host  interface,  although  the  actual  line  signals 
are  different  from  those  of  a  local  Host  connection. 

The  distant  Host  driver  performs  two  functions.  It  accommo¬ 
dates  a  shift  in  ground  potential  between  two  distant  systems  and 
it  provides  a  signaling  method  having  sufficient  power  and  noise 
resistance  to  communicate  over  a  2000-foot  separation.  The  refer¬ 
ence  level  for  the  logic  signals  is  shifted  in  the  driver  unit 
from  the  IMP  signal  reference  to  the  Host  signal  reference  by 
transformer  coupling.  The  Host  reference  is  then  carried  to  the 
distant  Host  driver  through  the  cable  shield.  Within  the  distant 
Host  cable,  signals  are  transmitted  on  twisted  pairs  as  balanced 
differential  signals  that  permit  rejection  ax'  induced  common  mode 
noise . 

A  prototype  driver  has  been  successfully  tested  on  a  2000- 
foot  cable  loop  and  production  versions  will  be  available  early 
in  the  spring. 
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4.  PHONE  LINE  TEST  PROGRAM 

In  the  last  quarter,  we  designed  and  implemented  a  test  pro¬ 
gram  to  obtain  data  on  the  performance  of  the  fifty  kilobit  com¬ 
munication  circuits.  This  particular  test  program  continuously 
transmJ  short  packets  (88  bits)  on  each  phone  line  and  keeps 
track  of  arriving  packets  in  a  way  that  allows  the  real  time 
occurrence  of  packet  errors  to  be  recorded  on  the  console  tele¬ 
type.  In  addition,  it  records,  for  arriving  packets,  a  burst 
length  histogram  of  successive  correct  packets  and  successive 
packets  in  error. 

The  basic  operation  of  the  program  is  as  follows.  The  pro¬ 
gram  sends  out  in  each  packet  one  word  of  data  that  contains  a 
16-bit  cjunt.  The  count  is  incremented  by  one  for  each  trans¬ 
mitted  packet.  When  a  packet  arrives  without  error,  the  new 
count  is  compared  with  the  last  received  count  and  any  difference 
greater  than  one  is  taken  to  indicate  an  error  burst. 

Two  different  types  of  line  test  can  be  run.  A  two-way 
line  test  may  be  run  whenever  the  remote  modem  is  looped  back. 

Two  one-way  line  tests  may  be  run  whenever  the  remote  modem  is 
not  looped  and  another  copy  of  the  test  program  is  running  the 
neighboring  IMP. 

Preliminary  two-way  test  data,  obtained  during  a  27-hour 
period  on  the  UCSB-SRI  line  (looped  back  at  SRI),  indicates 
approximately  one  packet  per  20,000  ir  error.  However,  subse¬ 
quent  tests  have  uncovered  a  100?  variation  in  this  number  — 
apparently  due  to  many  unusually  long  periods  of  time  (on  the 
order  of  hours)  with  no  detected  errors.  The  distribution  of 
error  bursts  appears  to  be  concentrated  in  the  range  between  one 
and  seven  packets. 


7 


Report  No.  1928 


Bolt  Beranek  and  Newman  Inc. 


5.  HOST  PROTOCOL 

Under  this  contract,  the  primary  BBN  responsibility  has  been 
the  implementation  of  an  IMP  subnet  and  the  related  connection  of 
the  subnet  to  the  Host  computers.  In  addition  to  this  development 
effort,  the  utility  of  the  ARPA  Network  is  dependent  upon  the  for¬ 
mulation  of  sensible  Host  protocols.  The  difficulty  of  this  task 
reflects  the  basic  underlying  research  problem  of  how  local  and 
remote  computer  programs  should  Interact.  Informal  efforts  to 
generate  a  Host  protocol  have  been  in  progress  for  some  time,  and 
an  informal  "Network  Working  Group"  exists  as  one  forum  for  dis¬ 
cussions.  In  the  last  quarter,  BBN  has  increased  its  participation 
In  these  efforts*  and  we  expect  to  continue  this  participation  in 
the  next  quarter. 

It  is  apparent  that  the  development  of  a  Host  protocol  in¬ 
volves  some  interaction  between  BBN  and  the  Hosts  on  the  subject 
of  IMP  protocol.  As  one  result  of  this  interaction,  a  minor 
change  is  being  made  m  the  RPNM  mechanism  to  simplify  an  aspect 
of  Host/Host  traffic  control.  A  Host  that  wishes  to  stop  the 
flow  of  incoming  traffic  on  a  given  link,  or  on  all  links,  simply 
notifies  its  IMP  via  a  control  message.  The  IMP  then  sets  a 
special  control  bit  in  the  next  RFNM  it  returns  on  that  link.  It 
is  the  responsibility  of  the  transmitting  Host  to  interpret  this 
Information  and  stop  the  flow  of  traffic.  The  IMP  will  not  enforce 
this  blockage,  as  the  IMP  will  unblock  the  link  as  soon  as  the  RPNM 
returns.  A  Host-to-Host  message  is  required  to  restart  the  flow  on 
this  link.  We  anticipate  other  cases  where  small  IMP  protocol 
changes  will  be  useful  and  we  will  try  to  be  responsive  to  such 
needs . 

*Mucb  of  our  discussion  has  been  with  S0  Crocker  of  UCLA  and  we 
acknowledge  his  contribution. 
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More  generally,  we  have  been  participating  in  the  considera¬ 
tion  of  several  Host  protocol  issues.  For  example: 

1.  While  we  have  come  to  believe  that  the  IMP  should  not  do 
character  set  conversions,  there  is  still  an  immediate  need 
for  a  network-wide  teletype  character  set  into  and  out  of 
which  each  Host  translates  his  messages.  The  choice  is  arbi¬ 
trary,  and  the  need  for  a  decision  has  become  urgent  (already 
we  see  Hosts  converting  to  the  language  of  the  destination). 

We  recommend  the  adoption  of  8-bit  ASCII  with  the  8th  bit 
(checksum  bit)  set  to  a  1,  which  is  the  IMP*s  internal  char¬ 
acter  set.  This  choice  has  the  small  additional  advantage 
that  Hosts  may  send  messages  to  local  or  remote  IMP  teletypes 
without  an  additional  conversion.  As  network  use  develops, 
other  standards  (such  as  a  display  language)  will  be  needed. 

2.  With  regard  to  the  user  level  of  message  control,  we  recom¬ 
mend  the  notion  of  user  ports  whereby  a  user  may  request  to 
establish  a  port  with  a  specific  port  number.  The  user  may 
request  to  send  messages  from  one  port  to  another,  or  to 
receive  messages  at  a  port  from  either  a  specific  port  or 
from  any  port.  Standard  programs  in  each  Host  (the  logger, 
the  message  box,  etc.)  would  have  standard  published  numbers 
and  would  be  generally  available  for  use.  We  hope  to  partici¬ 
pate  in  further  detailing  of  this  approach. 

3-  A  potential  conflict  exists  over  how  to  handle  echoing.  Local 
echoing  is  troublesome  for  systems  that  do  not  always  echo  the 
input;  remote  echoing  is  both  troublesome  for  systems  whose 
hardware  automatically  echoes  and  may  introduce  undue  echoing 
delay.  This  topic  deserves  further  study. 
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At  this  point  the  initial  network  is  installed  and  opera¬ 
tional.  New  Hosts  wiU  be  entering  the  network  at  a  rate  of  one 
a  month  for  the  next  several  months.  There  is  thus  an  urgent 
need  for  further  work  on  Host  protocol  and  for  documents  speci¬ 
fying  formats  and  procedures  for  Host— to— Host  communication. 
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Ts.  abstract  ,phe  bas^c  function  of  the  IMF  computer  network  is  to  allow  large 
existing  time-shared  (Host)  computers  with  different  system  configura¬ 
tions  to  communicate  with  each  other.  Each  IMP  (Interface  Message  Pro¬ 
cessor)  computer  accepts  messages  for  its  Host  from  ojher  Host  computers 
and  transmits  messages  from  its  Host  to  other  Hosts.  fMrice  there  will 
not  always  be  a  direct  link  between  two  Hosts  that  wish  to  communicate, 
individual  IMPS  will,  from  time  to  time,  perform  the  function  of  trans¬ 
ferring  a  message  between  Hosts  that  are  not  directly  connected.  This 
then  leads  to  the  two  basic  IMP  configurations  -  interfacing  between 
Host  computers  and  acting  as  a  message  switcher  ir.  the  IMP  network.  The 
message  switching  is  performed  as  a  store  and  forward  operation.  Each 
IMP  adapts  its  message  routine  to  the  condition  of  those  portions  of  the 
IMP  network  to  which  it  is  connected.  IMPs  regularly  measure  network 
performance  and  report  in  special  messages  to  the  network  measurement 
center.  Provision  of  a  tracing  capability  permits  the  net  operation  to 
be  studied  comprehensively.  An  automatic  trouble  reporting  capability 
detects  a  variety  of  network  difficulties  and  reports  them  to  an  inter¬ 
ested  Host.  An  IMP  can  throw  away  packets  that  it  has  received  but  not 
yet  acknowledged,  transmitting  packets  to  other  IMPs  at  i^s  own  discre¬ 
tion.  Self-contained  network  operation  is  designed  to  protect  and  deliv¬ 
er  messages  from  the  source  Host  to  the  destination  Host. 
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